H.323 is an emerging standard protocol for multi-media communication. This standard governs communications between terminals and other entities over a packet switched network. A person of ordinary skill in the art and who is familiar with the H.323 standard will understand the elements of establishing third party call control via a Gatekeeper. Briefly, upon powering up, a H.323 endpoint (desktop) implements a discovery process for determining which Gatekeeper to register with. This can be effected in a number of ways, such as by multicasting a message which identifies the endpoint (i.e. the GRQ (Gatekeeper Request) message) to a predetermined multicast address. The assigned Gatekeeper then responds (i.e. the GCF/GRJ (Gatekeeper Confirm/Gatekeeper Reject) message) with its RAS (Registration Admission Status) channel address (i.e. IP address). Before attempting to place a call, the endpoint must register with the Gatekeeper (i.e. the RRQ (Registration Request) message) by advising it of its transport address and any aliases (discussed below). Registration is then confirmed by the Gatekeeper (i.e. via the RCF/RRJ (Registration Confirm/Registration Reject) message). Actual call signaling takes place over and established channel between two H.323 endpoints using Q.931 messages. For third party (i.e. Gatekeeper) call control, the originating endpoint sends a H.225 Admission Request (ARQ) to the Gatekeeper over the previously established RAS channel. The Gatekeeper responds with an ACF (Admission Confirmation) message which specifies the call signaling transport address to use for the call setup. The originating endpoint then transmits a Setup message to the Gatekeeper which, in turn, sends a Setup message to the destination endpoint. The destination endpoint then sends an admission request (ARQ) to the Gatekeeper and receives an acknowledgment (ACF) therefrom. Finally, a Connect message is sent from the destination endpoint to the Gatekeeper which contains the address of the originating endpoint for H.425 control messages to the originating endpoint.
The inventors have recognized the desirability of adapting the H.323 standard protocol, or some other type of standard protocol, to voice communications such as traditionally implemented via a PBX. In the context of this contemplated telephony application, a call setup under the H.323 protocol requires two H.323 compliant endpoints to completely set up the call.
There are some features of PBXs, such as callback, recall, and make call (TAPI (Telephone Application Program Interface)), among others, which require the system to make a half call to a device, and only after there has been some user response at the device then initiate a full call between the two endpoints. For example, in order to ‘ring’ a device in a PBX, the system itself initiates ringing of the device (without any requirement to have actual communication between endpoints). Then, when the device is ‘answered’ (i.e. the user goes off hook), the PBX establishes a call between the two endpoints. The H.323 standard does not allow for such behavior since the protocol requires two H.323 endpoints in order to initiate and complete a call.
Also, there are group features, such as key line appearances, pickup groups, etc., that are necessary in a PBX, and which are not supported by the H.323 endpoint communication protocol. Group features are normally handled in the PBX call control, and many different device types can be members of groups. Since H.323 requires communication between distinct H.323 entities, it is not possible to establish features wherein multiple H.323 endpoints are arranged in a group. Similarly, it is not possible to select from a group of trunks or a particular trunk to make a call.